くらめその情シス：Azure AD 条件付きアクセスをMDMの条件でテストしてみる
はじめに
どうも、情シスの徳道です。これまでくらめその情シスシリーズではAzure ADやIntuneを連続して取り上げてきました。
AzureADによるリモートワーク時のユーザー認証やモバイルデバイスマネジメント、PCの自動セットアップなどのメリットと並び、AzureADを利用することの内部統制で期待を寄せているのが今回取り上げるAzureAD 条件付きアクセス（以下、条件付きアクセスと記載）です。
せっかくユーザー認証やデバイスがリモート環境でも集中管理できるようになったわけですから、それをどう活かすか、ということになると思います。
やはり社内システムへの安全なアクセスをさせたい、と思うのはどこでも同じではないでしょうか。
今回はAzureADとIntuneによるデバイス状態による条件付きアクセスがどのようになるか、実機でテストした結果を紹介したいと思います。
【ご注意ください】
条件付きアクセスを利用するためにはAzure Active Directory Premium P1以上のライセンスが必要となります。
また、モバイルデバイスマネジメントの利用にはIntuneのライセンスが必要です。
これまでのAzureADとIntuneの環境構築、ライセンスについてはこちらをご覧ください。
【AzureAD+Intuneを利用するために必要なライセンス】
テスト用のサービスプロバイダーを設定
条件付きアクセスでテストをするためには、アクセス先となるシングルサインオンのAzureのアプリが必要です。
気を付けないといけないのは現在利用しているかもしれないアプリを条件付きアクセスに設定しないようにすることですね。
（ユーザーに大迷惑をかけちゃいます。。。）
ステージング環境を持っていればいいのですが、そこまでしなくともテスト用のWebアプリを登録してしまえばいいわけです。
今回はこちらのSSOテスト用サービスプロバイダー（SP）のサイトを利用してみました（無料で利用可能です）
【SAML Test Service Provider】
https://sptest.iamshowcase.com/
なおこのセクションではこちらのサイトを参考にさせていただきました。厚く御礼申し上げます。
https://idmlab.eidentity.jp/2018/02/samlidpsp.html
SPのメタデータを取得する
今回は条件付きアクセスでアクセスができる/できない の確認ができればいいわけですね。
今回はSAML Test Service ProviderのURLにアクセスしたらAzureADで認証される、という想定で設定を行いました。
SAML Test Service Providerにアクセスしたら、上側にある「Instructions」のドロップダウンリストから「IDP Initiated SSO」をクリックします。
「DOWNLOAD METADATA」のボタンをクリックします。
XMLのメタデータが表示されますので、「entityID」と「AssertionConsumerService BindingのLocation」を探して値をメモしておきます。
下図の赤ラインの値です。
AzureADにSPのアプリを登録する
ここからAzureADでの操作です。SAML Test Service Provider のWebアプリを登録します。
「条件付きアクセス管理者ロール」と「アプリケーション管理者ロール」を付与されたユーザーでのログインが必要です。
Azure Active Directory での管理者ロールのアクセス許可
Azureのホームで「エンタープライズアプリケーション」を検索して開きます。
エンタープライズ アプリケーション | すべてのアプリケーション
「新しいアプリケーション」をクリックします。
「独自のアプリケーション作成」をクリックします。
適当にテストアプリ名を付けて作成します。ここでは「SP-SSO-TEST」にしました。
アプリが作成されると各種設定の画面になりますので、メニューの「シングルサインオン」→「SAML」を開きます。
ステップ１ 基本的なSAML構成 を編集して、識別子と応答URLに先ほどSAML Test Service Providerから取得した情報を設定します。
SAML構成を保存すると、SAML署名証明書が作成されますので、「フェデレーション メタデータXML」をファイルでダウンロードしましょう。
また、先にアクセステストをさせるAzureADユーザーもこのアプリに割り当てておきます。
SPにフェデレーションメタデータを設定する
SAML Test Service Providerに操作を戻します。
先ほどAzureADからダウンロードしたXMLファイルを「Setting up SP initiated SSO」の下にある 「CHOOSE FILE」に設定し、「SUBMIT FILE」をクリックします。
するとポップアップウィンドウが開き、URLが表示されます。これがSAML Test Service ProviderにAzureADからSSOをするURLです。
コピーしておきましょう。
余談ですが、同じフェデレーションメタデータを指定する限り、同じURLが発行されますので、誤って閉じてしまった場合はもう一度XMLファイルをSUBMITすれば大丈夫です。
SSOをテストする
では生成されたURLにアクセスしてみましょう。
最初にAzureADのログイン画面に遷移しました。ここでは先ほどアプリに割り当てたAzureADのユーザーIDでログインします。
AzureADのユーザーでログインできました！ユーザー名が表示され、画面の下にはSAMLのログインで取得された情報が表示されています。
これで条件付きアクセスをテストする準備ができました。
条件付きアクセスを設定する
条件
要件付きアクセスに設定するは以下としました。
【SAML Test Service Providerが以下の条件で表示されること】
- Windows、Macのブラウザ
- Intuneのデバイスポリシーに「準拠」しているマシンでのアクセス
- １、２以外の条件ではアクセスできないこと
-
- アクセス許可されたAzureADユーザーではない
- デバイスがIntuneに参加していない
- デバイスがIntuneのデバイスポリシーに準拠していない
条件付きアクセスのポリシー作成
AzureADに「条件付きアクセス管理者ロール」を付与されたユーザーでのログインしましょう。
ホームから「AzureAD 条件付きアクセス」を開きます。
「新しいポリシー」をクリックして作成していきます。
【ユーザーとグループの割り当て】
まずは条件付きアクセスの名前を付けましょう。今回はアプリと同じ名前にしていますが、もちろん任意です。
最初にAzureADユーザー化、グループを割り当てます。アプリのアクセス許可を与えたユーザー、またはグループと一致させておくことが基本形になると思います。社内基幹システムなどであればすべてのユーザーにしておくこともよいでしょう。
【アプリの割り当て】
この条件付きアクセスにアプリを割り当てます。
複数のアプリを割り当てることができるので、同一条件であれば一つにしておくと管理が楽になると思います。
【条件の割り当て】
続いて、この設定のキモであるアクセスを許可するための条件を設定します。
デバイスプラットフォームではOSやデバイスの種類を明示的に指定します。
スマホアクセスを許可しないなど、利用する組織のポリシーに従って選択すればよいと思います。
今回はテスト要件に従ってWindowsとMacだけにしました。
クライアントアプリはブラウザ想定です。先進認証クライアントはチェックをつけておきます。
レガシー認証クライアントはどんなものがあるのか私はちょっと想像できませんでしたが、ひとまず外しておきます。
この項目は「はい」としておきます。この項目を有効にすることで、Intuneでのコンプライアンスポリシー、デバイスポリシーに「準拠した」デバイスからのアクセスのみを許可することになります（Hybrid AzureAD joinedについては本稿では触れません）。
そしてアクセス制御の設定となります。
ここでは「許可」の制御だけにしておきます。今回のテストではページが開ければOKなので、セッションの設定はしていません。
許可項目の「多要素認証を要求する」「デバイス準拠しているとしてマーク済みである必要があります」だけにチェックをします。
ここで「多要素認証を要求する」を設定することで、すでにAzureにログイン済みのユーザーであっても、改めて多要素認証を義務付けることができ、一層セキュアにアプリアクセスをさせることができます。
【参考：Azureの多要素認証設定についてはこちらも併せてごらんください】
弊社の環境ではHybrid Azure ADを利用していないこと、ブラウザでのアクセスになるので、下の3点はチェックを入れません。 「承認されたクライアントアプリ～」や「Require app protection policy」はマイクロソフト製のアプリ等、でのアクセスに限定する場合なので、 Webアプリの追加の場合はチェックを入れないようにしましょう。
また、注意が表示されますが、Azure管理コンソールに条件付きアクセスを設定するときは操作をしている方のデバイスがポリシーに合致しているか確認しましょう。もし、操作している方のマシンがポリシーに準拠していないと管理画面にアクセスできなくなってしまいますので。。。
最後の設定です。ここまで設定をすると、最下部に以下の表示が現れます。
「オン」を選択して「作成」をすると、ポリシーが有効になります。
テストしてみる
では、早速要件に従ってテストしてみましょう。
以下の画面はAzureAD上で、私のユーザーに割り当てられているデバイスの一覧です。
こちらと、別のAzureADアカウントでSP-SSO-TESTの条件付きアクセスに設定していないユーザーをテストしてみます。
WindowsでChromeを使う場合は拡張アプリが必要
ここで準備が一つ。WindowsでChromeを利用して条件付きアクセスで制御されたアプリにアクセスする場合は、拡張アプリのインストールが必要です。
Chromeウェブストアから「Windows 10 Accounts」で探して追加をしてください（Mac版ChromeやEdge/Safariでは不要です）。
許可されたユーザー、ポリシーに準拠したデバイス
まず、私の個人ユーザーIDと、私の個人に割り当てられたWindowsPCから作成したSAML Test Service ProviderのURLにアクセスします。
おっと、多要素認証のコードを求められます。意図した動作ですね。
はい、問題なくアクセスできます。
同じく、私の個人ユーザーIDと、私の個人に割り当てられたMacからもアクセスしてみます。
もちろん、こちらも問題なくアクセスできました（Macの画面とわかるようにウィンドウでキャプチャ）。
許可されたユーザー、ポリシーに準拠していないデバイス
では次のテスト。
ユーザーは許可されており、Intuneに参加しているけれど、ディスク暗号化ができずポリシーに準拠していない WindowsPCからのアクセス。
ログイン～多要素認証までは許可されたデバイスと同じですが、以下の表示になってアクセスできませんでした。
意図通りの動作です。
許可されたユーザー、Intuneに参加していないデバイス
ユーザーは許可されており、Intuneに参加もしていないデバイス。もちろんアクセスできてはいけないです。
はい、メッセージが変わりました。もちろんアクセスはできません。デバイスの状態によって明示的にメッセージが変わるので、サポートする側としては切り分けがしやすいのは親切だと感じました。
許可されていないユーザー
では、そもそもユーザーが許可されていない場合も確認しておきます。マシンはIntuneに参加して準拠されたデバイスです。
こちらはそもそもがユーザーに権限がない、というエラーになります。これはデバイスの準拠以前なので、どのデバイスで試しても同じでした。
以上でテスト要件は全部〇でした！
- Windows、Macのブラウザ：〇
- Intuneのデバイスポリシーに「準拠」しているマシンでのアクセス：〇
- １、２以外の条件ではアクセスできないこと
-
- アクセス許可されたAzureADユーザーではない：〇
- デバイスがIntuneに参加していない：〇
- デバイスがIntuneのデバイスポリシーに準拠していない：〇
さいごに
リモートワークの定着が進んでいる昨今では社内システムへのアクセスにより神経を尖らせているシステム担当者の方もいると思います。
Idpにシングルサインオンを任せ、かつデバイスが正しいこと（会社で貸与、管理できているものでのログイン）を検出、制御できる仕組みがあるとインターネット経由での接続もさらにセキュアになると思います。
今回の検証をもとに社内システムに活用していければいいなと考えています。
実現の暁にはまた運用や切り替えのノウハウをご紹介できれば、と思います。
最後までお読みいただき、ありがとうございました！
